前言：回覆一則 issue，看起來是最容易外包的工作

「issue 回覆不就是打字嗎？AI 打字比人快多了，直接讓它代發不就好了？」

這句話聽起來有道理——回覆 issue 確實常常是重複性很高的工作：解釋一次「這個行為是預期的，不是 bug」、指向一次文件裡已經寫過的答案、確認一次「這個問題我們已經知道了，正在排隊處理」。表面上看,這正是 AI 最擅長的事。但「回覆 issue」這件事，其實藏著兩種完全不同性質的工作，而 AI 只該做其中一種。

今日目標

• 分清楚 issue 回覆裡「整理事實」跟「表達立場」這兩種不同性質的工作
• 理解為什麼「表達立場」不能交給 AI 自己決定
• 看一組具體對照，掌握該怎麼設計 AI 輔助回覆的分工
• 建立一套「AI 先草擬、人先看過才發」的具體流程

兩種性質不同的工作，混在同一個「回覆」動作裡

第一種是整理事實：這個問題是不是因為某個版本的行為改變、對應的文件段落在哪裡、有沒有類似的已知 issue 可以參照、重現這個問題需要補齊哪些資訊。這些工作的答案就在程式碼、commit 歷史、既有文件裡，判斷標準相對客觀——AI 讀得到這些素材，也做得出跟人類差不多品質的整理。

第二種是表達立場：要不要接受一個有爭議的功能請求、要怎麼回應一個語氣不太客氣的回報者、要不要對某個持續騷擾維護者的帳號設下界線、要不要承諾一個明確的修復時間表。這些問題的答案不在程式碼裡，在維護者的判斷裡——牽涉到專案的長期方向、對社群風氣的期待、維護者自己願意投入多少心力,這些都不是讀 issue 內容能推導出來的。

AI 可以幫忙做第一種工作,做得又快又準；但如果讓 AI 自己決定第二種工作該怎麼回、甚至直接代發，等於是讓一個沒有被授權的角色，替專案的立場說話。

一組對照：草擬 vs 代發

❌ 讓 AI 直接代發回覆：
一則 issue 提出一個會大幅改變既有 API 行為的功能請求，
AI 直接回覆：「這個想法不錯，我們會考慮加入下個版本。」
→ 這句話對外代表了專案的承諾,但這個承諾從沒有人真正拍板過，
  維護者事後才發現，已經有使用者拿這句話去問「什麼時候要上」

✅ 讓 AI 草擬、人核准後才發：
AI 整理：「這個功能請求會影響到 XX 既有行為，
  類似的討論在過去的 issue 裡出現過，當時的結論是……
  以下是我草擬的回覆，需要你確認語氣跟承諾範圍後再發出。」
→ AI 做的是「把決策需要的背景資訊準備好」，
  真正代表專案表態的那句話，由維護者自己按下發送

這兩種版本的差別，不是 AI 的文字能力好不好，而是「誰對這句話負最終責任」。 回覆一旦發出去，讀者會把它當成專案的立場，不會知道這句話是不是真的經過維護者本人同意——如果 AI 自己決定了語氣跟承諾範圍，維護者其實是在事後才追認一個自己沒參與過的決定。

為什麼這條界線特別容易被模糊掉

跟程式碼審查不一樣，issue 回覆常常有時效性壓力——一則回報放著沒回應好幾天，容易讓回報者覺得專案沒人維護；如果 AI 可以即時代發，這個壓力感覺上能被解決。但**「即時」不代表「不需要人看過」**——草擬跟核准這兩個動作可以壓縮得很快（維護者花 10 秒看一眼草稿、確認語氣沒問題就發），跟「完全跳過人的判斷」是兩件事。

PHPUnit & Pest Test Explorer 這個專案累積下來的 issue，大多數確實是「整理事實」這一類——回報者附上錯誤訊息，維護者需要判斷是不是已知問題、指向對應的修復進度。這類回覆讓 AI 先草擬草稿，維護者花的時間會大幅縮短；但一旦碰到功能方向的討論、或者回報者的語氣需要拿捏，還是要維護者自己決定要說什麼。

今日思考題

回想你自己維護的專案（如果有的話）：上一次回覆一則 issue 時，那則回覆裡有沒有一句話，其實隱含了一個你自己都還沒真正拍板的立場？如果讓 AI 代發，那句話會不會變成一個你事後才發現的承諾？

今日重點回顧

• Issue 回覆裡混著「整理事實」跟「表達立場」兩種性質不同的工作
• AI 適合做整理事實：查文件、比對已知 issue、確認重現步驟是否齊全
• AI 不該自己決定表達立場：功能方向、語氣拿捏、承諾範圍，這些要維護者自己負責
• 具體做法是「AI 草擬、人核准才發」，不是完全交給 AI 代發，也不是完全不用 AI

明日預告

明天要講一個更明確的界線：授權跟版權判斷——當一個外部貢獻牽涉到授權條款相容性、或版權歸屬有爭議時，這是另一類 AI 不該自己決定的維護者責任。